Skip the dense copy of the sparse arguments in a sparse-plus-scalar broadcast such as A .+ 1 - #1105

Since #1004, a broadcast sum of a sparse array and a scalar, such as A .+ 1, is dense. It gets there by copying every sparse argument into a dense array, then broadcasting over the copies into a second dense array. For a sparse argument with few stored entries, that copy is half the memory and more than half the time.

Before (main; random n×n sparse A, B of density d; minimum time over 20 runs)

After

Sums with a dense array, such as A .+ M and v .+ M, are unchanged.

The new path evaluates the broadcast once with each sparse argument replaced by its implicit zero. That fills every entry of the result that no stored entry reaches. It then evaluates the broadcast again only at the entries a stored entry is broadcast to. The function is a tree of + and -, so evaluating it twice at an entry is unobservable. Results match dense broadcast in type and isequal, including NaN and -0.0. I checked that against dense on 36 expressions over Float64, ComplexF64, Bool and Int entries, with sparse vectors and 1-row and 1-column matrices broadcast across the result.

Each re-evaluated entry looks up every sparse argument. So the new path runs only while the entries reached, times the number of sparse arguments, stay below 1/32 of the result; otherwise the dense copy is cheaper. Above that density, as in the 0.5 row and for A .+ B .- 2 at 0.01, the old path runs.

Left out:

• Sums with a dense array argument. Measured near the cutoff, the copy was not their main cost, and the new path was slower.
• Adjoints, transposes and views of sparse arrays, which are still copied.
• Element types that are not Number, and abstract ones such as Real. Their implicit zero can have another type than the result that dense broadcast infers from the values, so the old path runs whenever the two types differ.

🤖 Generated with Claude Code